Collection of Tools & Utilities/Collection of Tools and Utilities.iso/edit/dte5_1.zip/DTE.DOC

Text File | 1991-02-06 | 22KB | 399 lines

BACKGROUND
==========

"dte" is a simple full-screen text editor suitable for editing program
source code. It was designed with the following goals:
    1. To perform well over slow serial communication lines;
    2. To imitate the command keys used in WordStar / Turbo Pascal;
    3. To be readily portable to different hardware.

Slow serial communication lines pose some unique problems for full-
screen text editors. On a 1200 baud line, a 24 line by 80 column
screen can take up to 16 seconds to transmit (although with normal
program text 8 seconds would be more typical, since most lines will
not be the full 80 columns). Most text editors simply input a command,
update the screen to show the effect of the command, then input
another command and so on. Usually this is acceptable. However,
consider the case where the user types the command to move a page down
in the file, then immediately changes his mind and types the command
to move back up a page. Between when the user entered the first
command and when he entered the second command, the computer might
have updated one or two lines on the screen. After the second command
was entered, the computer should only have had to undo these few
changed lines. However, with many text editors, the computer would
completely finish updating the screen before the second command was
even registered, and then have to completely redraw the screen to make
it the way it used to be - a total of about 16 wasted seconds for the
poor user! "dte" notices commands as soon as they are typed, and
always updates the screen to match the desired final state.

If the user is to be able to take full advantage of this ability to
enter new commands before the screen is completely updated from
earlier ones, then it would be helpful if the lines closest to the
cursor could be updated before the rest of the screen; this would give
the user a context in which to decide what to do next. "dte" always
updates the cursor line first, and then alternately updates lines
above and below the cursor until the screen is complete.

There has been much debate over whether modeless editors are
intrinsically easier to use than editors with all sorts of modes. My
personal view is that modes are acceptable in two situations:
    1. The mode can be left set for an entire editing session;
    2. The mode only lasts for the next keystroke, then reverts to
       normal automatically.
I believe the problems usually arise when modes last for some time,
but must be changed periodically during a normal editing session. The
problem is increased if the difference between what the same
keystrokes achieve is drastically different between different modes.

"dte" has several modes in the first class. Insert mode determines
whether normal printable characters typed will be inserted in front of
the cursor, or whether they will overwrite the character under the
cursor. Insert mode will usually be left on all the time, and if the
user forgets which mode he is using, the worst effect will be the loss
of a few characters that get overwritten by characters that were
intended to be inserted. Indent mode determines whether, when the user
types the carriage return key, the new line inserted will begin in
column 0, or will be indented to match the line above. Indent mode
will usually be left on for program editing, and if the user forgets
which mode is in effect all that will be needed to correct the problem
is to insert or delete a few spaces. Finally, unindent mode determines
whether, when the cursor is on the first non-blank character of a line
and the user types backspace, just one character should be deleted, or
whether enough characters should be deleted to match the indentation
of an earlier line. Unindent mode will normally be on for program
editing, and if the user forgets which mode is in effect, the only
problem will be a few too many or too few spaces deleted.

"dte" also has several modes in the second class. Since "dte" has over
50 different commands, it was not possible to use a different control
key for each command. Therefore, some control keys have been reserved
as "escape" keys, to create two-key commands. In these cases, the mode
is indicated by a small marker in the top left corner of the screen,
and the mode only lasts until the next single key has been pressed.

"dte" does have a few commands that do not fit either class. For
example, the command to find the next occurrence of a particular
string requires the user to enter the search string. In these cases,
the user is prompted for whatever needs to be entered. These
exceptions seem inevitable - after all, if normal characters were
always inserted at the cursor, it would not (readily) be possible to
search for a string containing normal characters!

Since "dte" was to be a relatively modeless editor, and yet at the
same time was to work with typical so-called "intelligent" terminals,
it was assumed that only printable ASCII characters and control codes
could be returned by the terminal. Thus all of the "dte" commands had
to be constructed from the control codes. My personal view is that
MicroPro did an excellent job of this mapping with WordStar, and
evidently Borland agree since the default commands for Turbo Pascal
are also WordStar compatible where appropriate. Even if I had not
liked this set of commands, I would still have been almost forced to
use it, since most of my potential users were already familiar with
Turbo Pascal.

This is the other major advantage of "dte" over the existing full-
screen text editors on our UNIX minicomputer: it uses a set of
commands that are already familiar to most of the staff and students
from using microcomputers. For a student who normally uses Turbo
Pascal on a microcomputer, and only logs in to the minicomputer to
send electronic mail, it is very frustrating to have to learn a
complete new set of editor commands! Many simply ignore the electronic
mail facility, which makes life difficult for staff who have to try to
debug programs by telephone instead!!

One of my more interesting design decisions was what to do about
moving the cursor beyond the last character in a line. WordStar does
not allow this (the cursor simply cannot be moved anywhere unless
there is actually a character there in the text). On the other hand,
Turbo Pascal permits the cursor to be placed anywhere. Since "dte" was
to be a program editor, I chose the Turbo Pascal approach. However, I
then had the problem of what to do about trailing white space at the
end of a line. All the user has to do is type a character when the
cursor is beyond the end of a line, and then delete the character
again, and there will be a number of spaces hanging at the end of the
line wasting memory. If this trailing space is removed as soon as the
cursor leaves the line (the Turbo Pascal approach), then there is a
problem: if the cursor is beyond the end of the line, and the user
types the carriage return key, then changes his mind and types the
backspace key, the cursor finishes up at the end of the visible text
of the line, not where it started from. To avoid this, I have left the
trailing space there, but removed it when starting to edit a line (by
which time the cursor is already positioned). Trailing space is also
removed as the file is being saved to disk. Thus, although it is
possible to get some wasted memory in trailing space, the problem is
not likely to accumulate over time!

Initially, "dte" did not worry about file attributes (read/write/
execute) at all: if a file was read only, then after editing it had to
be saved to a different name, and every file saved was simply given
the default attributes. However, this caused problems with editing
shell scripts, since every time a file was saved it lost its "execute"
attribute! Now "dte" notes the attributes of a file when it starts
editing, changes these attributes temporarily so the owner can write
the file to save an edited version (if the file was read only), and
finally changes the attributes back to what they wer